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METHOD AND SYSTEM FOR COUPLING 
AN X.509 DIGITAL CERTIFICATE WITH A HOST IDENTITY 



BACKGROUND OF THE INVENTION 

5 

1. Field of the Invention 

The present invention relates to an improved data 
processing system and, in particular, to a method and 
apparatus for multicomputer data transferring. Still more 
10 particularly, the present invention provides a method and 
apparatus for computer- to-computer authentication. 

2 • Description of Related Art 

The commercial use of the Internet has dramatically 

15 increased the use of technology. During the early adoption 
of the Internet for commercial use, one would frequently 
learn of enterprises that were moving legacy applications to 
the World Wide Web or introducing Internet functionality 
into these legacy applications. Web-based and 

20 Internet-based applications have now become so commonplace 
that when one learns of a new product or service, one 
assumes that the product or service will incorporate 
Internet functionality into the product or service. New 
applications that incorporate significant proprietary 

25 technology are only developed when an enterprise has a 
significantly compelling reason for doing so. 

Many corporations have employed proprietary data 
services for many years, but it is now commonplace to assume 
that individuals and small enterprises also have access to 

30 digital communication services. Many of these services are 
or will be Internet-based, and the amount of electronic 
communication on the Internet is growing exponentially. 
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One of the factors influencing the growth of the 
Internet is the adherence to open standards for much of the 
Internet infrastructure. Individuals, public institutions, 
and commercial enterprises alike are able to introduce new 
5 content, products, and services that are quickly integrated 
into the digital infrastructure because of their ability to 
exploit common knowledge of open standards. 

Concerns about the integrity and privacy of electronic 
communication have also grown with adoption of 

10 Internet-based services. Various encryption and 

authentication technologies have been developed to protect 
electronic communication. For example, an open standard 
promulgated for protecting electronic communication is the 
X.509 standard for digital certificates. 

15 An X.509 digital certificate is an International 

Telecommunications Union (ITU) standard that has been 
adopted by the Internet Engineering Task Force (IETF) body. 
It cryptographically binds the certificate holder, 
presumably the subject name that the certificate contains, 

20 with its public cryptographic key. This cryptographic 

binding is based on the involvement of a trusted entity in 
the Internet Public Key Infrastructure (PKIX) called the 
"Certifying Authority". As a result, a strong and trusted 
association between the certificate holder and its public 

25 key can become public information yet remain tamper-proof 
and reliable. 

An important aspect of this reliability is a digital 
signature that the Certifying Authority stamps on a 
certificate before it is released for use. Subsequently, 
30 whenever the certificate is presented to a system for use of 
a service, its signature is verified before the subject 
holder is authenticated. After the authentication process 



3 

AUS9-2000-0255-US1 

is successfully completed, the certificate holder may be 
provided access to certain information and/or services. 

Many legacy systems have been updated with open 
standard functionality, such as X.509 certificates, so that 
5 system services are widely available yet secure. Although 
an updated legacy system may be more conveniently accessed 
through the Internet or through a corporate intranet, there 
may be justifiable reasons for not modifying certain 
systems. Hence, many enterprises have legacy systems that 

10 are being maintained but not updated with new technologies. 

Most legacy systems ensure secure access through the 
use of a password or other secret or secure information, 
such as biometric identifiers, that must be simultaneously 
asserted along with a user's identity. Since an individual 

15 may have many identities on different legacy systems, legacy 
systems are relatively inconvenient to use. The methodology 
of securing access to legacy systems can present barriers to 
enterprise-wide goals of enhancing efficiency and workflow 
compared with newer or updated interconnected systems that 

20 employ open standards for authentication. 

Therefore, it would be advantageous to have a method 
and system in which secure user access to a legacy system 
could be provided through an interconnected system without 
the necessity of modifying the legacy system. It would be 

25 particularly advantageous to use the trusted relationships 
associated with digital certificates in order to 
authenticate user access to these legacy systems. 
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SUMMARY OF THE INVENTION 

The present invention is a method or system for 
coupling identities through the use of digital certificates, 
thereby allowing a client to be authenticated for a variety 
of services without those services having to modify their 
existing methods of authentication. 

The client generates a request for a digital 
certificate containing its host identity for a targeted host 
and secret data associated with its host identity. The 
secret data has been encrypted using the public key of the 
certifying authority that receives the request for the 
digital certificate. The certifying authority decrypts the 
secret data using its private key and encrypts the secret 
data using the public key of the targeted host. The digital 
certificate is then generated and returned to the client. 

A host receives the digital certificate from the client 
and obtains the client's host identity from the digital 
certificate, i.e. the host identity uniquely identifies the 
client or the user of the client to the host. Encrypted 
secret data associated with the host identity, such as a 
password, is also retrieved from the digital certificate. 
During an authentication process, the secret data securely 
associates the host identity with the entity that presents 
the host identity. The host decrypts the secret data with 
its private key, and the host then authenticates the client 
using the host identity and the decrypted secret data for 
various services. The digital certificate may be formatted 
according to the X.509 standard, and the host identity and 
secret information may be stored in an X.509 extension 
within the digital certificate. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims . The 
invention itself, further objectives, and advantages 
thereof, will be best understood by reference to the 
following detailed description when read in conjunction with 
the accompanying drawings, wherein: 

Figure 1A depicts a typical distributed data processing 
system in which the present invention may be implemented; 

Figure IB depicts a typical computer architecture that 
may be used within a data processing system in which the 
present invention may be implemented; 

Figure 2 depicts a typical manner in which an entity 
obtains a digital certificate; 

Figure 3 depicts an entity that may be authenticated to 
different systems or applications in different manners; 

Figure 4 shows a simplified manner of using a digital 
certificate for a variety of purposes in accordance with the 
present invention; 

Figure 5 shows some of the fields of a standard X.509 
digital certificate; 

Figure 6 shows the structure of a host identity mapping 
extension for use within an X.509 certificate in accordance 
with a preferred embodiment of the present invention; 

Figure 7 depicts the use of a host identity mapping in 
accordance with a preferred embodiment of the present 
invention; and 

Figures 8A-8C are flowcharts depicting the processing 
of a digital certificate for authenticating a certificate 
holder on a system using the identity mapping methodology of 
the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

5 With reference now to the figures, Figure 1A depicts a 

typical network of data processing systems. Each of the data 
processing systems shown in Figure 1A may implement the 
present invention. Distributed data processing system 100 
contains network 101, which is the medium used to provide 

10 communications links between various devices and computers 

connected together within distributed data processing system 
100. Network 101 may include permanent connections, such as 
wire or fiber optic cables, or temporary connections made 
through telephone or wireless communications. In the 

15 depicted example, server 102 and server 103 are connected to 
network 101 along with storage unit 104. In addition, 
clients 105-107 also are connected to network 101. Clients 
105-107 and servers 102-103 may be represented by a variety 
of computing devices, such as mainframes, personal computers, 

20 personal digital assistants (PDAs), etc. Distributed data 
processing system 100 may include additional servers, 
clients, routers and other devices not shown. In the 
depicted example, distributed data processing system 100 may 
include the Internet with network 101 representing a 

25 worldwide collection of networks and gateways that use the 
TCP/IP suite of protocols to communicate with one another. 
Of course, distributed data processing system 100 may also 
include a number of different types of networks, such as, for 
example, an intranet, a local area network (LAN) , or a wide 

30 area network (WAN) . 

The present invention could be implemented on a variety 
of hardware platforms. Figure 1A is intended as an example 
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of a heterogeneous computing environment and not as an 
architectural limitation for the present invention. 

With reference now to Figure IB, a diagram depicts a 
typical computer architecture of a data processing system, 
5 such as those shown in Figure 1A, in which the present 

invention may be implemented. Data processing system 110 
contains one or more central processing units (CPUs) 112 
connected to internal system bus 113, which interconnects 
random access memory (RAM) 114, read-only memory 116 , and 

10 input/output adapter 118, which supports various I/O 

devices, such as printer 120, disk units 122, or other 
devices not shown, such as a sound system, etc* System bus 
113 also connects communication adapter 124 that provides 
access to communication link 126. User interface adapter 

15 128 connects various user devices, such as keyboard 130 and 
mouse 132, or other devices not shown, such as a touch 
screen, stylus, etc. Display adapter 134 connects system 
bus 113 to display device 136. 

Those of ordinary skill in the art will appreciate that 

20 the hardware in Figure IB may vary depending on the system 
implementation. For example, the system may have one or 
more processors, and other peripheral devices may be used in 
addition to or in place of the hardware depicted in Figure 
IB. The depicted examples are not meant to imply 

25 architectural limitations with respect to the present 

invention. In addition to being able to be implemented on a 
variety of hardware platforms, the present invention may be 
implemented in a variety of software environments. A 
typical operating system may be used to control program 

30 execution within the data processing system. 
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The present invention may be implemented on a variety 
of hardware and software platforms, as described above. 
More specifically, though, the present invention is directed 
to providing an identity mapping methodology that secures 
5 user access to applications or systems within a distributed 
data processing environment. To accomplish this goal, the 
present invention uses the trusted relationships associated 
with digital certificates in a novel manner to authenticate 
user access for an application or system. Before describing 

10 the present invention in more detail, though, some 

background information about digital certificates is 
provided for evaluating the operational efficiencies and 
other advantages of the present invention. 

Digital certificates support public key cryptography in 

15 which each party involved in a communication or transaction 
has a pair of keys, called the public key and the private 
key. Each party's public key is published while the private 
key is kept secret. Public keys are numbers associated with 
a particular entity and are intended to be known to everyone 

20 who needs to have trusted interactions with that entity. 

Private keys are numbers that are supposed to be known only 
to a particular entity, i.e. kept secret. In a typical 
public key cryptographic system, a private key corresponds 
to exactly one public key. 

25 Within a public key cryptography system, since all 

communications involve only public keys and no private key 
is ever transmitted or shared, confidential messages can be 
generated using only public information and can be decrypted 
using only a private key that is in the sole possession of 

30 the intended recipient. Furthermore, public key 

cryptography can be used for authentication, i.e. digital 
signatures, as well as for privacy, i.e. encryption. 



AUS9-2000-0255-US1 

Encryption is the transformation of data into a form 
unreadable by anyone without a secret decryption key; 
encryption ensures privacy by keeping the content of the 
information hidden from anyone for whom it is not intended, 
5 even those who can see the encrypted data. Authentication 
is a process whereby the receiver of a digital message can 
be confident of the identity of the sender and/or the 
integrity of the message. 

For example, when a sender encrypts a message, the 

10 public key of the receiver is used to transform the data 
within the original message into the contents of the 
encrypted message. A sender uses a public key to encrypt 
data, and the receiver uses a private key to decrypt the 
encrypted message. 

15 When authenticating data, data can be signed by 

computing a digital signature from the data and the private 
key of the signer. Once the data is digitally signed, it 
can be stored with the identity of the signer and the 
signature that proves that the data originated from the 

20 signer. A signer uses a private key to sign data, and a 

receiver uses the public key to verify the signature. The 
present invention is directed to a form of authentication 
using digital certificates; some encryption is also 
performed during the processing within the present 

25 invention. 

A certificate is a digital document that vouches for 
the identity and key ownership of entities, such as an 
individual, a computer system, a specific server running on 
that system, etc. Certificates are issued by certificate 

30 authorities. A certificate authority (CA) is an entity, 
usually a trusted third party to a transaction, that is 
trusted to sign or issue certificates for other people or 
entities. The CA usually has some kind of legal 
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responsibilities for its vouching of the binding between a 
public key and its owner that allow one to trust the entity 
that signed a certificate. There are many such certificate 
authorities, such as Verisign, Entrust, etc* These 
5 authorities are responsible for verifying the identity and 
key ownership of an entity when issuing the certificate. 

If a certificate authority issues a certificate for an 
entity, the entity must provide a public key and some 
information about the entity. A software tool, such as 

10 specially equipped Web browsers, may digitally sign this 

information and send it to the certificate authority. The 
certificate authority might be a company like Verisign that 
provides trusted third-party certificate authority services. 
The certificate authority will then generate the certificate 

15 and return it. The certificate may contain other 

information, such as dates during which the certificate is 
valid and a serial number. One part of the value provided 
by a certificate authority is to serve as a neutral and 
trusted introduction service, based in part on their 

20 verification requirements, which are openly published in 
their Certification Service Practices (CSP) . 

Typically, after the CA has received a request for a 
new digital certificate, which contains the requesting 
entity's public key, the CA signs the requesting entity's 

25 public key with the CA's private key and places the signed 
public key within the digital certificate. Anyone who 
receives the digital certificate during a transaction or 
communication can then use the public key of the CA to 
verify the signed public key within the certificate. The 

30 intention is that an entity's certificate verifies that the 
entity owns a particular public key. 

The X.509 standard is one of many standards that 
defines the information within a certificate and describes 
the data format of that information. The "version" field 
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indicates the X.509 version of the certificate format with 
provision for future versions of the standard. This 
identifies which version of the X.509 standard applies to 
this certificate, which affects what information can be 
5 specified in it. Thus far, three versions are defined. 

Version 1 of the X.509 standard for public key certificates 
was ratified in 1988. The version 2 standard, ratified in 
1993, contained only minor enhancements to the version 1 
standard. Version 3, defined in 1996, allows for flexible 

10 extensions to certificates in which certificates can be 

extended in a standardized and generic fashion to include 
additional information. 

In addition to the traditional fields in public key 
certificates, i.e. those defined in versions 1 and 2 of 

15 X.509, version 3 comprises extensions referred to as 

"standard extensions". The term "standard extensions" 
refers to the fact that the version 3 of the X.509 standard 
defines some broadly applicable extensions to the version 2 
certificate. However, certificates are not constrained to 

20 only the standard extensions, and anyone can register an 

extension with the appropriate authorities. The extension 
mechanism itself is completely generic. 

Other aspects of certificate processing are also 
standardized. The Certificate Request Message Format (RFC 

25 2511) specifies a format recommended for use whenever a 
relying party is requesting a certificate from a CA. 
Certificate Management Protocols have also been promulgated 
for transferring certificates. More information about the 
X.509 public key infrastructure (PKIX) can be obtained from 

30 the Internet Engineering Task Force (IETF) at www.ietf.org. 

With reference now to Figure 2, a block diagram depicts 
a typical manner in which an individual obtains a digital 
certificate. User 202, operating on some type of client 
computer, has previously obtained or generated a 

35 public/private key pair, e.g., user public key 204 and user 
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private key 206. User 202 generates a request for 
certificate 208 containing user public key 204 and sends the 
request to certifying authority 210, which is in possession 
of CA public key 212 and CA private key 214. Certifying 
authority 210 verifies the identity of user 202 in some 
manner and generates X.509 digital certificate 216 
containing signed user public key 218 that was signed with 
CA private key 214. User 202 receives newly generated 
digital certificate 216, and user 202 may then publish 
digital certificate 216 as necessary to engage in trusted 
transactions or trusted communications. An entity that 
receives digital certificate 216 may verify the signature of 
the CA by using CA public key 212, which is published and 
available to the verifying entity. 

With reference now to Figure 3, a block diagram depicts 
an individual that may be authenticated to different systems 
or applications in different manners. Figure 3 reflects the 
inefficiency in maintaining user identities in different 
manners on different systems. 

User 302 possesses X.509 digital certificate 304, which 
is transmitted to an Internet or intranet application 306 
that comprises X.509 functionality for processing and using 
digital certificates. The entity that receives certificate 
304 may be an application, a system, a subsystem, etc. 
Certificate 304 contains a subject name or subject 
identifier that identifies user 302 to application 306, 
which may perform some type of service for user 302. 

User 302 may authenticate to other systems by sending 
authentication data 308 comprising identity information and 
some type of secret information, such as a password. Host 
system 310 receives authentication data 308, which can be 
reconciled with identity information in system registry 312, 
and host system 310 may then allow user 302 to use its 
services and resources. Although not shown in the figure, 
user 302 may have other identities on other host systems, 
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which would require multiple sets of authentication data 
similar to authentication data 308. 

Figure 3 shows a problem that can arise when a user has 
multiple identities within an enterprise—the multiple 
identities may be decoupled, thereby forcing the systems 
within the enterprise to perform different methods of 
authentication. The subject name within the certificate is 
possibly unknown to many applications running on host 
systems, particularly legacy applications, yet the 
certificate holder may have an associated identity on the 
host systems. Because the identities are decoupled, a host 
application server may be prevented from taking advantage of 
the reliable authentication methodology that an X.509 
certificate provides at lower level authentication 
protocols, such as a Secure Socket Layer (SSL) stack. 

With reference now to Figure 4, a block diagram shows a 
simplified manner of using a digital certificate for a 
variety of purposes in accordance with the present 
invention. A more complete description of the present 
invention is provided with respect to Figures 7-8C. Figure 4 
merely provides a simple manner of observing the additional 
functionality provided by the present invention compared to 
prior art methodologies as shown in Figure 3. 

User 402 possesses X.509 certificate 404 that contains 
HostlDMapping 406, which is implemented as an extension 
within the certificate, as explained in more detail with 
respect to Figure 6. User 402 can send certificate 404 to 
various Internet /intranet applications 408, as is typically 
performed in the prior art. 

However, given that certificate 404 contains HostID 
mapping information 406, certificate 404 may also be 
transmitted to host system 410. Host system 410 has 
knowledge of various other identities of user 402 in system 
registry 412. Host system 410 retrieves the HostID mapping 
information from the certificate and obtains an identity and 
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associated secret information so that user 402 can be 
authenticated to various other applications or services 
within host system 410, such as legacy application 414, 
using only the presentation of certificate 404. A separate 
transmittal of authentication data for legacy application 
414 is not required after the user is authenticated to the 
host system. 

With reference now to Figure 5, some of the fields of a 
standard X.509 digital certificate are shown. The 
constructs shown in Figure 5 are in Abstract Syntax Notation 
1 (ASN.l) and are defined within the X.509 standard. 

With reference now to Figure 6, a diagram shows the 
structure of a host identity mapping extension for use 
within an X.509 certificate in accordance with a preferred 
embodiment of the present invention. The host identity 
mapping extension, shown as HostlDMapping in Figure 6, is a 
construct that contains: hostName, which identifies the host 
on which the associated subject identifier is located; 
subjectID, which is the identity on the associated host that 
belongs to the certificate holder; and proof Of IdPossession, 
which has the contents as shown in the IdProof construct. 

The proofOf IdPossession data item is self-explanatory; 
it is used to prove that the certificate holder has 
possession of the named host identifier. The IdProof 
construct contains the secret information and an identifier 
for the encryption algorithm with which the secret data was 
encrypted. In other words, the subject identifier and the 
secret information in the host identity mapping extension 
serve a purpose similar to the identity and the password in 
authentication data 308 shown in Figure 3. 

The secret information in the IdProof construct is some 
type of authentication secret that should be known only to 
the certificate holder and the host system, which is usually 
a password but may be some type of biometric identification 
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information, etc. The secret information is encrypted in a 
process shown in more detail in Figure 7. 

The host identity mapping is implemented as an 
extension as provided by the X.509 standard. It should be 
5 noted, however, that the format of the extension containing 
the host identity mapping information could vary from the 
format shown in Figure 6* The present invention may also 
use other digital certificate standards or formats other 
than X.509 as long as the digital certificates can convey 

10 the required information. In addition, a single digital 

certificate may contain many host identities, which may be 
found within the digital certificate by searching through 
the host names, thereby allowing the digital certificate to 
support host identity mapping on multiple host systems. 

15 The proof Of IdPossession data item within the host 

identity mapping information should not be confused with the 
proof of possession (POP) of a private key. In a public key 
infrastructure, in order to prevent certain attacks and to 
allow a certificate authority to properly check the validity 

20 of the binding between an entity and a key pair, a receiver 
of a digital certificate may require that an entity prove 
that it has possession of (or is able to use) the private 
key corresponding to the public key for which a certificate 
is requested, 

25 With reference now to Figure 7, a block diagram depicts 

the use of a host identity mapping in accordance with a 
preferred embodiment of the present invention. By using the 
trusted relationships associated with digital certificates, 
the present invention is able to map the identity of the 

30 certificate holder to a host identity of the certificate 

holder within an application or system that does not support 
digital certificates. The central processing is provided by 
an intermediate host system, also termed the targeted host. 
Host system 700 provides services for clients, such as 

35 user 702. User 702, acting as a client entity of the public 
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key infrastructure, has previously obtained or generated a 
public/private key pair, e.g., user public key 704 and user 
private key 706. Host system 700 has previously published 
its certificate 708 containing its public key into network 
5 directory 710. 

User 702 generates a request for certificate 712 
containing encrypted host identity mapping data 714 and user 
public key 704. Encrypted host identity mapping data 714 is 
created by encrypting the password or other secret 

10 information that is associated with the identity by using 
the public key of certifying authority 716, which is 
published and available to user 702. 

The encrypted host identity mapping data may also 
comprise other host information as necessitated by the 

15 targeted host system. The format of the host identity 

mapping data may also vary depending upon the purposes and 
needs of a particular implementation of the present 
invention. The encrypted host identity mapping information 
may be generated in a variety of manners, such as encrypting 

20 both the host identity and its associated secret information 
or merely encrypting the secret information. The intention 
is that the secret information should be encrypted to 
prevent illicit capture and use of the secret information. 
However, the host identity or other host information may not 

25 necessarily require encryption. 

User 702 sends the request to certifying authority 
716, which is in possession of CA public key 718 and CA 
private key 720. 

Certifying authority 716 verifies the identity of user 

30 702 in some manner and determines whether to issue a digital 
certificate for user 702. If so, then certifying authority 
716 decrypts encrypted host identity mapping data 714 
(so-called CA-encrypted data, i.e. encrypted for use by the 
CA) using CA private key 720 and encrypts the host identity 

35 mapping data with the public key of host system 700 as found 
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in host certificate 708 stored in network directory 710, 
thereby generating encrypted host identity mapping data 726 
(so-called host-encrypted data, i.e. encrypted for use by 
the host). Certifying authority 716 then creates X.509 
digital certificate 722 containing signed user public key 
724 that was signed with CA private key 720 and encrypted 
host identity mapping data 726. 

User 702 receives newly generated digital certificate 
722, and user 702 may then publish digital certificate 722 
as necessary to engage in trusted transactions or trusted 
communications. An entity that receives digital certificate 
722 may verify the signature of the CA by using CA public 
key 718, which is published and available to the verifying 
entity. 

At some point in time after receiving the digital 
certificate, user 702 sends digital certificate 722 to host 
system 700, which is in possession of host public key 728 
and host private key 730. Host system 700 retrieves 
encrypted host identity mapping information 726 from the 
received certificate and employs host private key 730 to 
decrypt the encrypted secret information in the host 
identity mapping information. The retrieved identity and 
the decrypted secret information are then placed into 
authentication data 732, which is sent to legacy application 
734. If the digital certificate has multiple subject 
identifiers, i.e. host identities, each of the identities 
may have an associated password, and a single presentation 
of the digital certificate would allow the user to have 
access to applications and resources throughout the system. 

With reference now to Figures 8A-8C, flowcharts depict 
the processing of a digital certificate for authenticating a 
certificate holder on a system using the identity mapping 
methodology of the present invention. The processing begins 
in Figure 8A with a client system generating or obtaining a 
public /private key pair (step 802). The client also obtains 
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the public key of the certifying authority that will produce 
an X.509 certificate (step 804). The client possesses a 
host identity on a targeted host system and its associated 
secret information, such as a password. The client encrypts 
the host identity mapping information using the CA public 
key (step 806) and generates the certificate request 
containing the client public key and the encrypted host 
identity mapping information (step 808) . 

The client then sends the certificate request to the 
certifying authority (step 810) . Assuming that the 
certificate request was processed successfully, the client 
eventually receives and stores its certificate containing 
its signed client public key and the host identity mapping 
information that was encrypted using the public key of the 
targeted host system (step 812) . The processing is then 
complete for the phase of obtaining a certificate containing 
host identity mapping information for use within a targeted 
host system. 

The phase of generating the certificate within the 
certifying authority is shown in Figure 8B. The process 
begins when the certifying authority receives the 
certificate request from the client (step 820) . The 
certificate request contains the public key of the client 
and the encrypted host identity mapping information for the 
client or certificate holder. The certifying authority 
verifies the identity of the certificate requester in some 
manner (step 822), and proceeds only if a certificate should 
be issued. At some point, the certifying authority also 
obtains the host public key (step 826) . 

The certifying authority then decrypts the host 
identity mapping information from the certificate request 
using the private key of the certifying authority (step 
828) . The certifying authority encrypts the host identity 
mapping information using the previously obtained host 
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public key (step 830). Assuming the system is using X.509 
certificates, the encrypted host identity mapping 
information may be stored within an X.509 certificate using 
the extension mechanism provided by the X.509 standard. The 
certifying authority generates and signs a digital 
certificate for the client containing the signed client 
public key and the encrypted host identity mapping 
information (step 832). The certifying authority then 
returns the certificate to the client (step 834), and the 
process of generating the certificate is complete. 

The phase of using the certificate within the targeted 
host system is shown in Figure 8C. The processing begins 
when the client or certificate holder presents its 
certificate to the targeted host system (step 840) . The 
presented certificate contains encrypted host mapping 
information in addition to typical information that may be 
found within a digital certificate of this type. As noted 
previously, the certificate may contain multiple host 
identities that are to be used on multiple targeted host 
systems, although it might be assumed that there is a 
one-to-one relationship between the host identities in the 
certificate and the targeted host systems. 

The host system then verifies the client certificate 
(step 842) and decrypts the encrypted host identity mapping 
information using the host's private key (step 844). The 
host system retrieves the host identity of the certificate 
holder and its associated secret information, e.g., a 
password, from the decrypted information (step 846) . The 
host system then uses the received host identity and secret 
information to authenticate the certificate holder on 
another system, subsystem, application, server, etc. (step 
848) ♦ For example, the host system may act as a proxy for 
the client in order to perform the authentication process, 
whereby the client obtains access to the other system or 
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application without requiring the other system or 
application to contain digital certificate functionality 
(step 850) . The process of authenticating the client 
through the targeted host system is then complete. 
5 The advantages of the present invention should be 

apparent in view of the detailed description of the 
invention that is provided above. By using a novel 
extension value within a digital certificate called Proof of 
Identity Possession (PIP), the present invention performs an 

10 identity mapping by coupling the identity of a certificate 
holder of an X.509 digital certificate to its subject's 
identity as known to a host application server. In other 
words, a subject name within a certificate is mapped to a 
host application identity. Hence, the present invention 

15 uses the trusted relationships associated with digital 
certificates in order to authenticate user access for a 
legacy application or system, thereby authenticating users 
on a legacy application or system without the problems and 
costs of modifying a legacy application or system to include 

20 X.509 functionality. 

The solution provided by this invention can be used to 
implement single network sign-on based on X.509 
certificates. For example, a digital certificate may 
include many or all of a user's enterprise-wide identities. 

25 A user can perform a secure, sign-on operation during which 
the digital certificate is presented. Once the user has 
been authenticated within a distributed data processing 
system, though, the distributed data processing system can 
authenticate the user within systems, subsystems, and 

30 applications within the distributed data processing system. 
The user may then access all applications or systems in 
which the user has an assigned identity within the 
distributed data processing system. Thus, an enterprise 
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maintains desired security requirements while receiving the 
benefits of the latest public key infrastructure technology. 

It is important to note that while the present 
invention has been described in the context of a fully 
functioning data processing system, those of ordinary skill 
in the art will appreciate that the processes of the present 
invention are capable of being distributed in the form of 
instructions in a computer readable medium and a variety of 
other forms, regardless of the particular type of signal 
bearing media actually used to carry out the distribution. 
Examples of computer readable media include media such as 
EPROM, ROM, tape, paper, floppy disc, hard disk drive, RAM, 
and CD-ROMs and transmission- type media, such as digital and 
analog communications links. 

The description of the present invention has been 
presented for purposes of illustration but is not intended 
to be exhaustive or limited to the disclosed embodiments. 
Many modifications and variations will be apparent to those 
of ordinary skill in the art. The embodiments were chosen 
to explain the principles of the invention and its practical 
applications and to enable others of ordinary skill in the 
art to understand the invention in order to implement 
various embodiments with various modifications as might be 
suited to other contemplated uses. 
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CLAIMS 

What is claimed is: 

1. A method for authenticating a client within a 
distributed data processing system, the method comprising 
the steps of : 

receiving a digital certificate from the client at a 
host within the distributed data processing system; 

obtaining a host identity for the client from the 
digital certificate; 

retrieving host-encrypted secret data associated with 
the host identity from the digital certificate; 

decrypting the host-encrypted secret data with a host 
private key; and 

authenticating the client using the host identity and 
the decrypted secret data. 

2. The method of claim 1, wherein the host acts as a proxy 
for the client. 

3. The method of claim 1 further comprising: 
verifying the received digital certificate. 

4. The method of claim 1 further comprising: 
generating, at the client, a request for a digital 

certificate comprising host identity mapping data; 

sending the request for the digital certificate to a 
certifying authority (CA) ; and 

receiving a digital certificate comprising host 
identity mapping data from the certifying authority. 

5. The method of claim 4 further comprising: 
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storing the host identity in the request for the 
digital certificate; 

encrypting secret data associated with the host 
identity using a public key of the certifying authority to 
generate CA-encrypted secret data; and 

storing the CA-encrypted secret data in the request for 
the digital certificate, wherein the host identity and the 
CA-encrypted secret data comprise the host identity mapping 
data in the request for the digital certificate. 

6. The method of claim 4 further comprising: 

receiving, at the certifying authority, the request for 
a digital certificate; 

generating the digital certificate in response to the 
received request for the digital certificate; and 

sending the generated digital certificate to the 
client . 

7 . The method of claim 4 further comprising: 

retrieving CA-encrypted secret data from the host 
identity mapping data in the request for the digital 
certificate; 

decrypting the CA-encrypted secret data associated with 
the host identity using a private key of the certifying 
authority to generate decrypted secret data; 

encrypting the decrypted secret data associated with 
the host identity using a public key of the host to generate 
the host-encrypted secret data; and 

storing the host-encrypted secret data in the digital 
certificate, wherein the host identity and the 
host-encrypted secret data comprise the host identity 
mapping data in the digital certificate. 
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8. The method of claim 1 wherein the digital certificate 
comprises multiple host identities for multiple hosts within 
the distributed data processing system. 

9. The method of claim 1 wherein the digital certificate 
is formatted according to the X.509 standard. 

10. The method of claim 9 wherein the host identity and the 
host-encrypted secret data associated with the host identity 
is stored within an X.509 extension within the digital 
certificate. 

11. The method of claim 1 further comprising: 
performing multiple authentication processes within the 

distributed data processing system for the client through 
the host using information within the digital certificate. 

12. A method for generating a digital certificate, the 
method comprising the steps of: 

receiving, at a certifying authority (CA) , a request 
for a digital certificate from a client, wherein the request 
for a digital certificate comprises host identity mapping 
data ; 

generating the digital certificate in response to the 
received request for a digital certificate; and 

sending the generated digital certificate to the 
client, wherein the digital certificate comprises host 
identity mapping data from the certifying authority. 

13. The method of claim 12 further comprising: 
retrieving CA-encrypted secret data from the host 

identity mapping data in the request for a digital 
certificate; 
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decrypting the CA-encrypted secret data associated with 
a host identity using a private key of the certifying 
authority to generate decrypted secret data; 

encrypting the decrypted secret data associated with 
the host identity using a public key of a host to generate a 
host-encrypted secret data; and 

storing the host-encrypted secret data in the digital 
certificate, wherein the host identity and the 
host-encrypted secret data comprise the host identity 
mapping data in the digital certificate. 

14. An apparatus for authenticating a client within a 
distributed data processing system, the apparatus 
comprising: 

first receiving means for receiving a digital 
certificate from the client at a host within the distributed 
data processing system; 

obtaining means for obtaining a host identity for the 
client from the digital certificate; 

first retrieving means for retrieving host-encrypted 
secret data associated with the host identity from the 
digital certificate; 

first decrypting means for decrypting the 
host-encrypted secret data with a host private key; and 

authenticating means for authenticating the client 
using the host identity and the decrypted secret data. 

15. The apparatus of claim 14, wherein the host acts as a 
proxy for the client. 

16. The apparatus of claim 14 further comprising: 
verifying means for verifying the received digital 

certificate . 
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17. The apparatus of claim 14 further comprising: 

first generating means for generating, at the client, a 
request for a digital certificate comprising host identity 
5 mapping data; 

first sending means for sending the request for the 
digital certificate to a certifying authority (CA) ; and 

second receiving means for receiving a digital 
certificate comprising host identity mapping data from the 
10 certifying authority. 

18. The apparatus of claim 17 further comprising: 

first storing means for storing the host identity in 
the request for the digital certificate; 
15 first encrypting means for encrypting secret data 

associated with the host identity using a public key of the 
certifying authority to generate CA-encrypted secret data; 
and 

second storing means for storing the CA-encrypted 
20 secret data in the request for the digital certificate, 

wherein the host identity and the CA-encrypted secret data 
comprise the host identity mapping data in the request for 
the digital certificate. 

25 19. The apparatus of claim 17 further comprising: 

third receiving means for receiving, at the certifying 
authority, the request for a digital certificate; 

second generating means for generating the digital 
certificate in response to the received request for the 
30 digital certificate; and 

second sending means for sending the generated digital 
certificate to the client. 
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20, The apparatus of claim 17 further comprising: 

second retrieving means for retrieving CA-encrypted 
secret data from the host identity mapping data in the 
request for the digital certificate; 
5 second decrypting means for decrypting the CA-encrypted 

secret data associated with the host identity using a 
private key of the certifying authority to generate 
decrypted secret data; 

second encrypting means for encrypting the decrypted 
10 secret data associated with the host identity using a public 
key of the host to generate the host-encrypted secret data; 
and 

third storing means for storing the host-encrypted 
secret data in the digital certificate, wherein the host 
15 identity and the host-encrypted secret data comprise the 
host identity mapping data in the digital certificate. 

21* The apparatus of claim 14 wherein the digital 
certificate comprises multiple host identities for multiple 
20 hosts within the distributed data processing system. 

22. The apparatus of claim 14 wherein the digital 
certificate is formatted according to the X.509 standard. 

25 23. The apparatus of claim 22 wherein the host identity and 
the host- encrypted secret data associated with the host 
identity is stored within an X.509 extension within the 
digital certificate. 

30 24. The apparatus of claim 14 further comprising: 

performing means for performing multiple authentication 
processes within the distributed data processing system for 
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the client through the host using information within the 
digital certificate. 

25. An apparatus for generating a digital certificate, the 
apparatus comprising: 

receiving means for receiving, at a certifying 
authority (CA) , a request for a digital certificate from a 
client, wherein the request for a digital certificate 
comprises host identity mapping data; 

generating means for generating the digital certificate 
in response to the received request for a digital 
certificate; and 

sending means for sending the generated digital 
certificate to the client, wherein the digital certificate 
comprises host identity mapping data from the certifying 
authority. 

26. The apparatus of claim 25 further comprising: 
retrieving means for retrieving CA-encrypted secret 

data from the host identity mapping data in the request for 
a digital certificate; 

decrypting means for decrypting the CA-encrypted secret 
data associated with a host identity using a private key of 
the certifying authority to generate decrypted secret data; 

encrypting means for encrypting the decrypted secret 
data associated with the host identity using a public key of 
a host to generate a host-encrypted secret data; and 

storing means for storing the host-encrypted secret 
data in the digital certificate, wherein the host identity 
and the host-encrypted secret data comprise the host 
identity mapping data in the digital certificate. 
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27. A computer program product on a computer readable 
medium for use in a distributed data processing system for 
authenticating a client, the computer program product 
comprising: 

instructions for receiving a digital certificate from 
the client at a host within the distributed data processing 
system; 

instructions for obtaining a host identity for the 
client from the digital certificate; 

instructions for retrieving host-encrypted secret data 
associated with the host identity from the digital 
certificate; 

instructions for decrypting the host-encrypted secret 
data with a host private key; and 

instructions for authenticating the client using the 
host identity and the decrypted secret data. 

28. The computer program product of claim 27 , wherein the 
host acts as a proxy for the client. 

29. The computer program product of claim 27 further 
comprising: 

instructions for verifying the received digital 
certificate . 

30. The computer program product of claim 27 further 
comprising: 

instructions for generating, at the client, a request 
for a digital certificate comprising host identity mapping 
data; 

instructions for sending the request for the digital 
certificate to a certifying authority (CA) ; and 
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instructions for receiving a digital certificate 
comprising host identity mapping data from the certifying 
authority. 

5 31. The computer program product of claim 30 further 
comprising: 

instructions for storing the host identity in the 
request for the digital certificate; 

instructions for encrypting secret data associated with 
10 the host identity using a public key of the certifying 
authority to generate CA-encrypted secret data; and 

instructions for storing the CA-encrypted secret data 
in the request for the digital certificate, wherein the host 
identity and the CA-encrypted secret data comprise the host 
15 identity mapping data in the request for the digital 
certificate . 

32. The computer program product of claim 3 0 further 
comprising: 

20 instructions for receiving, at the certifying 

authority, the request for a digital certificate; 

instructions for generating the digital certificate in 

response to the received request for the digital 

certificate; and 
25 instructions for sending the generated digital 

certificate to the client. 

33. The computer program product of claim 30 further 
comprising: 

30 instructions for retrieving CA-encrypted secret data 

from the host identity mapping data in the request for the 
digital certificate; 
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instructions for decrypting the CA-encrypted secret 
data associated with the host identity using a private key 
of the certifying authority to generate decrypted secret 
data; 

5 instructions for encrypting the decrypted secret data 

associated with the host identity using a public key of the 
host to generate the host-encrypted secret data; and 

instructions for storing the host-encrypted secret data 
in the digital certificate, wherein the host identity and 
10 the host-encrypted secret data comprise the host identity 
mapping data in the digital certificate, 

34. The computer program product of claim 27 wherein the 
digital certificate comprises multiple host identities for 

15 multiple hosts within the distributed data processing 
system. 

35. The computer program product of claim 27 wherein the 
digital certificate is formatted according to the X.509 

20 standard. 

36. The computer program product of claim 35 wherein the 
host identity and the host-encrypted secret data associated 
with the host identity is stored within an X.509 extension 

25 within the digital certificate. 

37. The computer program product of claim 27 further 
comprising: 

instructions for performing multiple authentication 
30 processes within the distributed data processing system for 
the client through the host using information within the 
digital certificate. 
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38. A computer program product on a computer readable 
medium for use in a distributed data processing system for 
generating a digital certificate, the computer program 
product comprising: 

5 instructions for receiving, at a certifying authority 

(CA) , a request for a digital certificate from a client, 
wherein the request for a digital certificate comprises host 
identity mapping data; 

instructions for generating the digital certificate in 
10 response to the received request for a digital certificate; 
and 

instructions for sending the generated digital 
certificate to the client, wherein the digital certificate 
comprises host identity mapping data from the certifying 
15 authority. 

39. The computer program product of claim 38 further 
comprising : 

instructions for retrieving CA-encrypted secret data 
20 from the host identity mapping data in the request for a 
digital certificate; 

instructions for decrypting the CA-encrypted secret 
data associated with a host identity using a private key of 
the certifying authority to generate decrypted secret data; 
25 instructions for encrypting the decrypted secret data 

associated with the host identity using a public key of a 
host to generate a host-encrypted secret data; and 

instructions for storing the host-encrypted secret data 
in the digital certificate, wherein the host identity and 
30 the host-encrypted secret data comprise the host identity 
mapping data in the digital certificate. 
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40. A data structure representing a digital certificate for 
use in a data processing system, the data structure 
comprising: 

an issuer name; 
5 a signature; 

a subject name; and 

an extension, wherein the extension comprises a host 
identity and host-encrypted secret data associated with the 
host identity. 
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ABSTRACT OF THE DISCLOSURE 

METHOD AND SYSTEM FOR COUPLING 
AN X.509 DIGITAL CERTIFICATE WITH A HOST IDENTITY 



A method or system is presented for coupling identities 
through the use of digital certificates, thereby allowing a 
client to be authenticated for a variety of services without 
those services having to modify their existing methods of 
authentication. The client generates a request for a 
digital certificate containing its host identity for a 
targeted host and secret data associated with its host 
identity. The secret data has been encrypted using the 
public key of the certifying authority that receives the 
request for the digital certificate. The certifying 
authority decrypts the secret data using its private key and 
encrypts the secret data using the public key of the 
targeted host. The digital certificate is then generated 
and returned to the client. At some point in time, a host 
receives the certificate from the client and obtains the 
client's host identity from the certificate, i.e. the host 
identity uniquely identifies the client or the user of the 
client to the host. Encrypted secret data associated with 
the host identity, such as a password, is also retrieved 
from the digital certificate. The host decrypts the secret 
data with its private key, and the host then authenticates 
the client using the host identity and the decrypted secret 
data for various services. The digital certificate may be 
formatted according to the X.509 standard, and the host 
identity and secret information may be stored in an X.509 
extension within the digital certificate. 



103 




Prior Art 

Figure 1A 



1/9 

AUS9-2000-0255-US1 




I/O Adapter 



/\J36 



Monitor 




||/V130 ft /V 132 
Keyboard Mouse 



Communication 



Adapter ^124 



110 



Prior Art 

Figure 1B 



2/9 

AUS9-2000-0255-US1 



User 
Public Key 
204 



User 
Private Key 
206 



302 



202 



IT 




Request for Certificate 


208 




User 






Public Key 






204 













Figure 2 



X.509 Certificate 
304 



X.509 Certificate 


216 




User Public Key 






(Signed) 






218 













Serial Number xxxxx 
Issuer Name xxxxx 



Subject Name /C=US/0=IBM/OU=DEVT/CN=JSMITHy 
Signature xxxxx 



Certifying Authority 
210 



CA 
Public Key 
212 



CA 
Private Key 
214 




Internet/Intranet 
Application 
306 



Authentication Data 
308 

identity 
Password 



Host System 
310 



System Registry 
312 



Subject 


Password 


JSMITH 


xxxxxx 



Figure 3 



3/9 

AUS9-2000-0255-US1 



402 




X.509 Certificate 
404 



Serial Number xxxxx 
Issuer Name xxxxx 



Subject Name /C=US/0=IBM/OU=DEVT/CN=JSMITb 
Signature xxxxx 



HostID Mapping xxxxx 



36 



Internet/Intranet 
Application 
408 




Host System 
410 



System Registry 
412 



Subject 


Password 


JSMITH 


xxxxxx 
•■ ■ 



Legacy 
Application 
414 



Figure 4 



4/9 

AUS9-2000-0255-US1 



Certificate ::= SEQUENCE { 

tbsCertificate TBSCertif icate, 

signatureAlgorithm Algorithmldentif ier, 

signature BIT STRING } 

TBSCertif icate :: = SEQUENCE { 



version [o] 

serialNuraber 

signature 

issuer 

validity 

subject 

sub j e c t Publ i c Key Inf o 
issuerUniquelD [1] 
subjectUniquelD [2] 
extensions [3] 



Version DEFAULT vl, 

Certif icateSerialNumber, 

Algorithmldentif ier, 

Name, 

Validity, 

Name, 

Subj ectPublicKeylnfo, 
IMPLICIT Uniqueldentif ier OPTIONAL, 
IMPLICIT Uniqueldentif ier OPTIONAL, 
Extensions OPTIONAL } 



Version : : = INTEGER { vl(0), v2(l), v3(2) } 
Certif icateSerialNumber = INTEGER 



Validity = SEQUENCE { 
notBef ore 
notAf ter 

Time : : = CHOICE { 
utcTime 
generalTime 



Time, 
Time } 



UTCTime, 

GeneralizedTime } 



Uniqueldentif ier :: = BIT STRING 

Subj ectPublicKeylnfo : : = SEQUENCE { 

algorithm Algorithmldentif ier , 

subject Publ icKey BIT STRING } 

Extensions : := SEQUENCE SIZE (1..MAX) OF Extension 

: = SEQUENCE { 



Extension : : = 
extnID 
critical 
extnValue 



OBJECT IDENTIFIER, 
BOOLEAN DEFAULT FALSE, 
OCTET STRING } 
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POWER OF ATTORNEY: As a named inventor, I hereby appoint the following 
attorneys and/or agents to prosecute this application and transact all 
business in the Patent and Trademark Office connected therewith. 

John W. Henderson, Jr., Reg. No. 26,307; Thomas E. Tyson/ Reg. No. 28,S43 
James K. Barksdala, Jr., Reg. No. 24,031; Casimer X. Salys, Reg. No. 28,900 
Robert Carwell, Reg. No. 26,499; Douglas H . Lefeve, Reg. No. 2 6,193 

Jeffrey S. LaBaw, Reg. No. 31, 633 ; David A. Mims, Jr., Reg. 3 2, 70S; Volel 
Smile, Reg. No. 39,969; Anthony V. England, Reg. No. 35,129; Leslie A. Van 
Leeuwen, Reg. No. 42,196; Christopher A. Hughes, Reg. No. 26,914; Edward A. 
Pennington, Reg. No. 3 2,5B8; John E. Hoel, Reg. No. 26,279; Joseph C. Redmond, 
Jr., Reg. No. 18,753; Marilyn S. Dawkins, Reg. No. 31,140; Mark E. KcBurney, 
Reg. No. 33,114; and Joseph R. Burwell, Reg. No. 44,468. 

Send correspondence to: Joseph R. Burwell 

Law Office of Joseph R. Burwell 

P.O. Box 28022 

Austin, Texas 7 3755-8022 

and telephone calls to: (512) 597-1218 
and faxes to: (512) 597-1218. 



)R FIRST INVENTOR:^ ptessaoud Benantar 
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FULL NAME OF SOLE OR FIRST INVENTOR wj ELes.s aoud Benantar 
INVENTORS SIGNATURE; 
RES IDENCE : Austin, Texas 
CITIZENSHIP: Algeria 

POST OFFICE ADDRESS: 12113 Metric Blvd. At>t. 1631 

Austin, TX 

FULL NAME OF SECOND INVENTOR: Thomas L. Gindin 

INVENTORS SIGNATURE: DATE: 

RESIDENCE: Potomac, Maryland 
CITIZENSHIP; JJSA 

POST OFFICE ADDRESS: 12901 Stallion Court 

Potomac, MP 2 0854 

FULL NAME OF THIRD INVENTOR: Ivan Milman 

INVENTORS SIGNATURE: DATE: 
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DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below 
next to my name; 

_ I believe I am the original, first and sole inventor (if only one name 

is listed below) or an original, first and joint inventor (if plural names are 
listed below) of the subject matter which is claimed and for which a patent is 
sought on the invention entitled 

METHOD AND SYSTEM FOR CO UPLING AN X, 509 DIGITAL CERTIFICATE WITH A HOST 

IDENTITY 

the specification of which (check one) 
X_ is attached hereto. 



was filed on 



as Application Serial No, 
and was amended on 



(if applicable) 



I hereby state that I have reviewed and understand the contents of the above 
identified specification, including the claims, as amended by any amendment 
referred to above. 

I acknowledge the duty to disclose information which is material to the 
patentability of this application in accordance with Title 37, Code of Federal 
Regulations, §1.56. 

Li h o re !? Y claim forei 9 n priority benefits under Title 35, United States Code 
§119 of any foreign application { s ) for patent or inventor's certificate listed 
below and have also identified below any foreign application for patent or 
inventor's certificate having a filing date before that of the application on 
which priority is claimed: 

Prior Foreign Application (s) : Priority Claimed 



(Number) (Country) (Day /Month/ Year) 



Yes No 



I hereby claim the benefit under Title 35, United States Code, §120 of any 
United States application ( s) listed below and, insofar as the subject matter 
of each of the claims of this application is not disclosed in the prior United 
States application in the manner provided by the first paragraph of Title 35 
United States Code, §112, I acknowledge the duty to disclose information ' 
material to the patentability of this application as defined in Title 37 Code 
of Federal Regulations, §1.56 which occurred between the filing date of the 
prior application and the national or PCT international filing date of this 
application; 



Page 1 of 3 



DOCKET NUMBER: AUS9-2000-0255-US1 



(Application Serial #) 



(Filing Date) 



(Status) 



I hereby declare that all statements made herein of my own knowledge are true 
and that all statements made on information and belief are believed to be 
true; and further that these statements were made with the knowledge that 
willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the 
application or any patent issued thereon. 

POWER OF ATTORNEY: As a named inventor, I hereby appoint the following 
attorneys and/ or agents to prosecute this application and transact all 
business in the Patent and Trademark Office connected therewith. 

John W. Henderson, Jr., Reg. No. 26,907; Thomas E. Tyson, Reg. No. 28,543 
James H. Barksdale, Jr., Reg. No. 24, 091; Casimer K. Salys, Reg. No. 28,900 
Robert M. Carwell, Reg. No. 28,499; Douglas H. Lefeve, Reg. No. 26,193 
Jeffrey S. LaBaw, Reg. No. 31,633 ; David A. Mims, Jr., Reg. 32,708; Volel 
Emile, Reg. No. 39,969; Anthony V. England, Reg. No. 35,129; Leslie A. Van 
Leeuwen, Reg. No. 42,196; Christopher A. Hughes, Reg. No. 26,914; Edward A. 
Pennington, Reg. No. 32,588; John E. Hoel, Reg. No. 26,279; Joseph C. Redmond, 
Jr., Reg. No. 18,7 53; Marilyn S. Dawkins, Reg. No. 31,140; Mark E. McBurney, 
Reg. No. 33,114; and Joseph R. Burwell, Reg. No. 44,468. 

Send correspondence to: Joseph R. Burwell 

Law Office of Joseph R. Burwell 

P.O. Box 28022 

Austin, Texas 78755-8022 

and telephone calls to: (512) 597-1218 
and faxes to: (512) 597-1218. 



FULL NAME OF SOLE OR FIRST INVENTOR: Messaoud Benantar 

INVENTORS SIGNATURE: . DATE: 

RESIDENCE: Austin, Texas 
CITIZENSHIP: Algeria 

POST OFFICE ADDRESS: 12113 Metric Blvd. Ant. 1631 

Austin, TX 7 875 8 

FULL NAME OF SECOND IIWEJJ20R: Thomas L^ Gindin 

]: ^^L, ^.J^^.J^ DATE: Jfy?- O. 3#60 



INVENTORS SIGNATURE: 
RESIDENCE: Potomac, Maryland 
CITIZENSHIP: USA 
POST OFFICE ADDRESS: 



12901 Stallion Court 
Potomac, MP 20854 



FULL NAME OF THIRD INVENTOR: Ivan Milman 
INVENTORS SIGNATURE: 



DATE: 



Page 2 of 3 



DOCKET NUMBER: AUS9-2000-0255-US1 



RESIDENCE : Austin, Texas 
CITIZENSHIP: USA 

POST OFFICE ADDRESS: 0 Placid Place 

Austin. TX 78731 



Page 3 of 3 



09/21/00 08:00 FAX 5124361788 



TIVOLI SYSTEMS 



aoo2 



DOCKET NUMBER: AUS9-2000-0255-US1 



DECLARATION AND POWER OP ATTORKEY FOR PATENT APPLICATION 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below 
next to my name; 

I believe I am the original, first and sole inventor (if only one name 
is listed below) or an original, first and joint inventor (if plural names are 
listed below) of the subject matter which is claimed and for which a patent is 
sought on the invention entitled 

METHOD AND SYSTEM FOR COUPLING AN X>509 DIGITAL CERTIFICATE WITH A HOST 

IDENTITY 



the specification of which (check one) 

X is attached hereto. 

was filed on 

as Application Serial No. 

and was amended on 



I hereby state that I have reviewed and understand the contents of the above 
identified specification, including the claims, as amended by any amendment 
referred to above. 

I acknowledge the duty to disclose information which is material to the 
patentability of this application in accordance with Title 37, Code of Federal 
Regulations, §1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, 
§119 of any foreign application (sj for patent or inventor's certificate listed 
below and have also identified below any foreign application for patent or 
inventor's certificate having a filing date before that of the application on 
which priority is claimed: 

Prior Foreign Application (s) : Priority Claimed 



(if applicable} 



Yes 



(Number) 



(Country) 



(Day /Month/Year) 
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I hereby claim the benefit under Title 35, United States Code, §120 of any 
United States application (s ) listed below and, insofar as the subject matter 
of each of the claims of this application is not disclosed in the prior United 
States application in the manner provided by the first paragraph of Title 35, 
United States Code, §112/ I acknowledge the duty to disclose information 
material to the patentability of this application as defined in Title 37, Code 
of Federal Regulations, §1.56 which occurred between the filing date of the 
prior application and the national or PCT international filing date of this 
application: 



(Application Serial #) (Filing Date) (Status) 



I hereby declare that all statements made herein of my own knowledge are true 
and that all statements made on information and belief are believed to be 
true; and further that these statements were made with the knowledge that 
willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the 
application or any patent issued thereon. 

POWER OF ATTORNEY: As a named inventor, I hereby appoint the following 
attorneys and/or agents to prosecute this application and transact all 
business in the Patent and Trademark Office connected therewith. 

John W. Henderson, Jr., Reg. No. 26,907; Thomas E- Tyson, Reg. No. 28,543; 
James H. Barksdale, Jr., Reg. No. 24,091; Casimer K. Salys, Reg. No. 28,900; 
Robert M. Carwell, Reg. No. 28,499; Douglas H. Lefeve, Reg. No. 26,193; 
Jeffrey S. LaBaw, Reg. No. 31, 633; David A. Mims, Jr., Reg. 32,708; Volel 
Entile, Reg, No. 39,969; Anthony V. England, Reg. No. 35,129; Leslie A, Van 
Leeuwen, Reg. No. 42,196; Christopher A. Hughes, Reg. No. 26,914; Edward A. 
Pennington, Reg. No. 32,533; John E . Hoel, Reg. No. 26,279; Joseph C. Redmond, 
Jr., Reg. No. 18,753; Marilyn S. Dawkins, Reg. No. 31,140; Mark E. McBuraey, 
Reg. No. 33,114; and Joseph R. Burwell, Reg. No. 44,468. 

Send correspondence to: Joseph R. Burwell 



Law Office of Joseph R. Burwell 

P.O. Box 28022 

Austin, Texas 78755-8022 



and telephone calls to: (512) 597-1218 
and faxes to: (512) 557-1218. 



FULL NAME OF SOLE OR FIRST INVENTOR: Messaoud Banantar 



INVENTORS SIGNATURE: 



DATE: 



Page 2 of 3 



SEP 21 2000 09:10 



5124361788 



PPGE.03 



09/21/00 08:01 FAX 5124361788 



TIVOLI SYSTEMS 



®004 



DOCKET NUMBER: AUS9-2 000-0255 -US1 

RES IDENCE : Austin, Texas 
CITIZENSHIP : Algeria 

POST OFFICE ADDRESS: 12113 Metric Blvd. Ant- 1631 

Austin, TX 79759 

FULL NAME OF SECOND INVENTOR: Thomas L. Gindin 

INVENTORS SIGNATURE: . DATE: 

RESIDENCE: Potomac, Maryland 
CITIZENSHIP: USA 

POST OFFICE ADDRESS: 12901 Stallion Court 

Potomac, MP 208 54 



DATE: 5y)L,JL- H^JCO 
RESIDENCE : Austin. Texas 
CITIZENSHIP: 

POST OFFICE ADDRESS; Jfr-E lmlQ Pluee 9^°^ Attkcw*} DtiW ^ 

_ Austin, TX WAt 7t W {fx 



FULL NAME OF THIRD INVENTQR: Ivan Milman 
INVENTORS SIGNATURE: 




SEP 21 2000 09=10 



Page 3 of 3 



I 
i 

5124361788 PAGE. 04 



